This is G o o g l e's cache of http://www.rockbox.org/twiki/bin/view/Main/BreakingTheLawForRecording as retrieved on 8 Sep 2005 08:48:20 GMT.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
This cached page may reference images which are no longer available. Click here for the cached text only.
To link to or bookmark this page, use the following url: http://www.google.com/search?q=cache:87I66HJdCI4J:www.rockbox.org/twiki/bin/view/Main/BreakingTheLawForRecording+breakingthelawforrecording&hl=en&client=firefox


Google is neither affiliated with the authors of this page nor responsible for its content.
These search terms have been highlighted: breakingthelawforrecording 

Rockbox . Main . BreakingTheLawForRecording

 Rockbox Logo 

home
download
documentation
mailing lists
wiki
IRC
forums
daily builds
feature requests
bug reports
patches


SourceForge.net Logo

Rockbox > Main > BreakingTheLawForRecording
Main . { Users | Changes | Index | Search | Register | Go }

Breaking the law for ergonomic recording screen behaviour

Motivation

I'd like to break ui design rules for the recording screen for the sake of ergonomy; specificially the rule that says "always return to where you come from". After you have recorded something you usually want to do something with that recording. Typical actions are:
  • rehearsal of the recording ("Whoa, listen to that guitar lick!")
  • delete the file ("That take was crap!")
  • rename the file
  • return ("Oops, I entered recording screen accidently, haven't recorded anything, just want to get back where I came from.");

Current behaviour

Nearly all of these actions require many, many, reeealy many clicks today. In the most relevant cases you have to quit the menu, browse to the recording directory and locate the file - of which you have forgotten the name meanwhile.

Task oriented exit behaviour

I'd prefer a task oriented behaviour where rockbox intelligently provides you with the tools for your next natural actions. Generally the recording screen behaves the way it alway did. Especially there's no change in how recordings are started and stopped. While a recording is in progress hitting stop once stops the recording but remains in the recording screen. Then you can decide wether you want to start another recording or leave the recording screen by hitting stop again. But leaving the recording screen should perform one of these actions (depending on settings and context):
rockbox action has recorded resume setting
show wps, playback recording when has recorded resume on
show browser, select recorded file when has recorded resume off
return to main menu when nothing recorded x

The dependence on the resume option is questionable. Maybe it's preferrable to always return to the tree browser. Because it is so easy to toggle between wps and tree browser it's not that important either.

"Play last recording" button

I already tried another approach: Make the on button a "play the last recording" button. (see patchtracker) Here too the recording screen behaves as it always did. But another way to exit the recording screen has been added: the on button. When something has been recorded and no recording is in progress it takes you to wps and plays the last recording. I think that it feels cheesy because:
  • There's a risk that you press stop twice by user error. That still takes you to the main menu and you have to go through the entire button click orgy to locate the recording.
  • Two recording screen exit points with different behaviour feel even more confusing than one exit point with task-oriented exit behaviour
  • It doesn't feel logical to /quit/ the recording screen with an /on/ button.
  • difficult to implement on targets with fewer buttons
  • unnecessary option quantities require user intelligence although rockbox could provide that intelligence
  • Although confusing this approach might be a compromise for design-rule-hardliners.

I really prefer the "task oriented" approach. But before putting any effort into that I'd like to discuss this.

{ Edit | View raw | Attach | Ref-By | Printable | Diffs | r1.3 | > | r1.2 | > | r1.1 | More }
Revision r1.3 - 07 Sep 2005 - 08:54 GMT - PhilippPertermann Copyright © 1999-2005 by the contributing authors.